Conclusions and Discussion

在這二十幾天來的技術文章分享，我們可以看到每個開發功能面的架構與流程，我們從最基層註解模式講到最上層的註解模式，都是顧慮到一個重點：共用性，身為開發者的你，無論多大多小都要保留彈性，讓未來相關功能可以一起共用，在抽象出許多種不同的模式運用，區分其應用領域，如同註冊功能而言，無論何種元件，追究至底層，都只是一個Bean元件，只是區分很多種不同領域模式的註解，並加強他的額外功能，一個系統的強大不在於它的技術有多新潮，有多漂亮的架構，只有在你的“齒輪”設計顆粒度有多漂亮，一樣的道理，Spring 註解式架構是多麽的新潮、多麽的炫，追究至底層，他還是用既有的BeanFactory元件進行獲取Bean元件，新只是一種方式，技術依舊，小編還是維持那句話：『沒有新舊技術，只有你不知道的好用技術，就是新技術』，分享這麼多天技術底層架構，小編也追逐很多樣式的前後端新技術，最後還是選擇回到最原有的底層架構，因為它終究是最重要的基底，所以，從這邊可以看出，很多還是沿用原有的框架，不用無謂汰舊換新，那只會讓你的寶貴資料模型無謂犧牲，如何讓既有的技術框架保有原有思想，並持續重構的迎接新的技術思想，才是重要的未來課題。這也是小編為什麼要拿Spring框架來當成功的技術案例分享。無論在於結構、效能、測試、微服務及監測等，都具備各種優勢，可從此分析是一項非常穩定的框架，雖然在某些元件齒輪的技術上，尚有不足與重工，如同　Reactor雖好，但依舊在重構，效能面依舊存在議題，新舊版本不相容，以下相關結論提供給各位開發者作參考。

Implementation

最後各位可看到完成後的系統服務架構(圖一)如下，我們並整合Spring 各式註解模式、Swagger API範例及Spring Reactor功能，並在整合Spring Actuator 套件終端點接口，開發了一套服務服務監測服務，進行監測服務運作的過程與異常。

圖一、產品系統結構

透過圖二我們可看出，監測支援非常全面化，可支援客製化終端點、記憶體資訊監測、Bean資訊監測、系統健康資訊監測、系統環境配置及排程資訊等等，可提供給開發者快速透過此監測服務的相關資訊進行障礙排除，資訊可以比JConsole更佳完整。

圖二、修改後服務系統監測介面

圖三、傳統介面監測畫面

以上為這三十天來的技術分享實作內容，分享給大家做參考，若有相關問題可在與我聯繫喔，但我小編很忙，會很晚才回，謝謝。

Future plans

未來在後端的開發規劃，小編評估Spring將朝向效能優化及完整的Lambda開發模式編程，在整合透過新式的垃圾回收(Garbage Collection，GC)機制提升其效率，畢竟現在整合套件多樣化，但如何有效的控管各套件執行緒效率是另外一個值得探討的議題，在於設計模式方面相對應整合功能多，但部分舊技術已出現不相容的情況，導致各個Repository越切越細是值得深思的議題，這樣只會變得相容度越來越低，這也是小編為什麼透過其他Script整合部分套件功能原因。

Acknowledgment

感謝我媽生了我，讓我依舊無聊的發呆活著，感謝我的指導教授，讓我知道在研究室就是要待到半夜，這樣在業界就習慣了～非常好！這是真的！謝謝鄭教授～謝謝，感謝第一間公司的架構師，他點醒了我，我開尋找新未來，太棒了～我覺得人生充滿了希望！謝謝大家！

就是現在！Rignt now！Currently！！At present！！！我已經不是小編拉！！！！！我是真新鎮的威斯丁，夢想是成為無聊程式訓練大師，讓我們開始我們成為程式訓練大師之路努力吧！謝謝大家 掰掰

Darius Weisting.